Various types of attacks are possible in the Internet, such as those known as the TCP SYN flood, Ping of Death and Land attacks. In addition to being vulnerable to all of these, wireless communications networks, including cellular networks, present characteristics that make them vulnerable to new attacks, or even more vulnerable to current existing ones. For example, the air interface of cellular networks is a scarce, limited and expensive resource that a user is required to pay for. As a result, new types of attacks are specifically directed to disrupting the air interface, such as an overbilling type of attack reported to the GSM Association in 2002. In brief, this attack operated by flooding arbitrary victims using TCP connections that were preestablished and left unclosed by the malicious party. The overbilling attack, operated with private and public Internet Protocol (IP) addresses, did not require the victim to establish a connection and bypassed (stateful) firewalls. The overbilling attack was equally effective whether the victim was in his home network or was roaming.
Unsolicited incoming traffic can lead to many undesired effects for both the subscriber and the operator. These include, but are not limited to, overbilling attacks, unnecessary consumption of the network operator's resources and a reduction in the victim battery's lifetime. However, in order to support Push Services and other future applications and scenarios (e.g., wireless terminals that host servers), valid incoming packets must be able to reach the wireless terminal of a cellular user. Unfortunately, this requirement opens the door for even more attacks on wireless terminals (also referred to as Mobile Stations (MSs), such as cellular telephones and other types of wireless-enabled devices, including personal digital assistants (PDAs)).
The 3GPP2 standards have recognized this problem, and a Network Firewall Control and Configuration (NFCC) effort has examined possible solutions to minimize unsolicited traffic and also minimize the opportunities for external parties to maliciously attack mobile stations (see 3GPP2 Network Firewall Configuration and Control—Stage 1 Requirements, December 2004).
Most applications supported thus far in cellular networks are based on the client-server model (e.g., web browsing) where cellular subscribers connect to servers in the external networks. With the connections being initiated by the wireless terminals, the deployment of stateful inspection packet filters has thus far provided adequate protection for both users and operators (see, for example, Check Point NG VPN-1/FireWall-1; Jim Noble et al., Syngress Publishing Inc., 2003).
However, when considering new applications (e.g., Push Services and Peer-to-Peer (P2P) applications) and scenarios to be supported (e.g., wireless terminals hosting servers), wireless terminals will not always be clients, but may instead function as servers. As a consequence, connections may have to be initiated by end points in the external networks towards the wireless terminals in the cellular networks, and incoming packets must be able to reach the wireless terminals.
This type of operation may, however, lead to different types of attacks since incoming traffic may be malicious traffic. Referring to FIG. 1A, a malicious node 1 may be sending traffic via external networks 2, such as the Internet, through a firewall 3 to the cellular network 4. From the cellular network 4, the malicious traffic passes through the air interface 5 to the victim wireless terminal 6. The wireless terminal 6 is assumed to be associated with a cellular network subscriber. This can result in various problems in the cellular network 4, such as the above-noted problems related to overbilling, reduction in the victim's battery lifetime, and unnecessary consumption of air interface bandwidth.
What is needed, therefore, is a technique to minimize the unsolicited traffic towards the wireless terminal 6, and, more specifically, a technique to reduce the occurrence or likelihood of an attack on wireless (e.g., cellular) network subscribers.
In 3GPP2, a suggestion has been made to use the following method to reduce the threat of malicious incoming traffic to the wireless terminal 6: It was suggested that every first incoming packet should pass the firewall 3 protecting the cellular network 4; if the terminal 6 decides to accept the invitation and set up the connection, the terminal 6 replies, and based on the terminal's reply, the firewall 3 creates a state for subsequent packet(s) corresponding to this flow; if the terminal 6 decides not to accept the connection, it does not reply. In the absence of a reply from the terminal 6, the firewall 3 blocks all subsequent incoming packets corresponding to this flow.
This proposed solution presents several issues, and does not actually reduce the threat, since in most Denial of Service (DoS) attacks the source IP address field is forged. As such, the malicious node 1 may thus still flood cellular subscribers with invalid incoming traffic (the malicious node 1 need only send many “first messages” whose source IP address is randomly created).
Other solutions to this problem have been suggested. For example, Feng et al. have suggested the use of a challenge-response based method at the IP layer, re-using puzzles to verify the validity of the source IP address of the packets (Wu-chang Feng, Ed Kaiser, Wu-chi Feng, Antoine Luu, “The Design and Implementation of Network Puzzles”, in Proceedings of INFOCOM 2005, March 2005). However, adoption of this approach would require modifications to the Internet Protocol (v4 and v6).
P2P applications, HTTP and most other applications run over TCP. Several extensions to TCP have been proposed to reduce potential DoS attacks, including the use of TCP cookies (see SYN cookies, D. J. Bernstein, at http://cr.yp.to/syncookies.html) and the TCP cache (see, Resisting SYN flood DoS attacks with a SYN cache, J. Lemon, in Proceedings of USENIX BSDCon 2002, San Francisco, February 2002). However, these approaches would still require that the potentially malicious packets reach the end point and would thus not protect the air interface 5 in the case where the wireless terminal 6 is the end point.
The SYN Relay approach (Check Point NG VPN-1/FireWall-1; Jim Noble et al., Syngress Publishing Inc., 2003) may partly solve the problem since in this method the firewall 3 responds to all SYN packets on behalf of the server by sending the SYN/ACK to the client. Once the ACK is received from the client, the firewall 3 passes the connection to the server. Using this method, it is assumed that the server never receives invalid connection attempts because the firewall 3 does not pass on the original SYN packet until it has received the corresponding ACK from the client. While this technique may offer protection for the server (terminal 6 in this case), which would include protection for the air interface 5, the firewall 3 needs to function as a relay between the server and the client. This imposes a significant overhead at the firewall 3 and, most importantly, it breaks the end-to-end property of the connection since the TCP connection from the client 1 stops first at the firewall 3, which then recreates another TCP connection to the server. One result of this approach is that the TCP sequence numbers at the terminal 6 and at the firewall 3 will differ, resulting in an inability to use IPsec. This approach would also create difficulties if the TCP connection needs to be secured by other means, including Transport Layer Security (TLS).
It would therefore be desirable to provide techniques that address these security concerns.